Technical Field:
This disclosure relates generally to optimizing compilation in a data processing system and more specifically to managing aliasing constraints in optimizing compilations in the data processing system.
Description of the Related Art:
Existing programming languages have provided some form of scope restricted pointers to a programmer, for example, block scope restricted pointers in C programming language and dummy arguments in FORTRAN programming language. In C, a block-scope restricted pointer makes an aliasing assertion limited to the scope of the pointer. In the scope of the restricted pointer, a target object of the pointer will not be accessed through any pointer that was not copied from the pointer and two such restricted pointers cannot be used to access the same object while the pointers are both within the scope. It is often critical for compilers to exploit these scope restricted aliasing rules to achieve runtime performance.
Current compilers often perform analysis for only those restricted pointers that are parameters or function scope variables and thus forego improved aliasing for block scope restricted pointers, because the analysis of scope restricted aliasing is difficult to represent. Traditional support for function-scope restricted pointers also introduces several issues. A separate shadow (an artificial symbol to represent the effect of dereferencing a pointer) is created for each restricted parameter and a flag is set on the shadow to indicate aliasing of the shadow can be refined to anti-alias to all other parameter shadows on the same function. Shadowing may create an explosion in the number of symbols with different aliasing that must be represented. Also, this shadowing may create problems for optimizations that move code across function call boundaries (for example, after in-lining or inter-procedural code motion, the restricted parameters are block scoped in the called function) because the refined aliasing for the specific shadow may not be sufficient outside of their associated scope. The problem arises because in a compiler the alias relationship for two symbols, whether alias or do not alias each other, is true for all accesses to these symbols throughout the whole program. For scope restricted pointers, although a certain level of scope restricted aliasing can be achieved by using different shadows to access the same storage on different parts of the program, there is typically no explicit mechanism, to prevent accesses to those shadows from migrating outside of their corresponding section of control. Therefore, there is a need to enable compilers to apply more aggressive aliasing for restricted pointers on specific regions of code for better runtime performance.